1 LIGHTWEIGHT DYNAMIC SERVICE CONVERSATION CONTROLLER 

2 Technical Field 

3 The technical field relates to E-Services communication. 

4 Background 

5 Distributed computing has evolved from intra-enterprise application integration, where 



6 application developers work together to develop and code to agreed upon method interfaces, to 

7 inter-enterprise integration, where E-Services may be developed by independent enterprises with 

8 completely disjoint computing infrastructures. To accommodate the change, E-Services, which 

9 may include services, agents, and web-services, should be able to communicate and exchange 

10 business data in a meaningful way, and having some degree of flexibility and autonomy with 

1 1 regard to the interactions. 



12 Several existing agent systems allow services/agents to communicate following 

1 3 conversational protocols. However, all of these agent systems are tightly coupled to specific 

14 service/agent systems, and require that all participating entities built upon a common 

1 5 service/agent platform. 

16 For example, Bradshaw, J.M. provides an open distributed architecture for software 



17 agents, the Knowledgeable Agent-oriented System (KAoS)> in the 1996 issue of "Knowledge 

18 Acquisition for Knowledge-Based Systems Workshop," entitled "KaoS: An Open Agent 

19 Architecture Supporting Reuse, Interoperability, and Extensibility " However, KAoS requires 

20 agent developers to hard-wire conversation policies into agents in advance. 

21 Walker, A. and Wooldridge, M. address the issue of how a group of autonomous agents 

22 can reach a global agreement on conversation policy in the 1 995 issue of "First International 

23 Conference on Multi- Agent Systems," entitled " Understanding The Emergence Of Conventions 

24 In Multi-Agent Systems ." However, Walker and Wooldridge require the agents themselves to 

25 implement strategies and control. 

26 Chen, Q., Dayal, U., Hsu, M., and Griss, M. provide a framework in which agents can 

27 dynamically load conversation policies from one-another in the 2000 issue of "First International 

28 Conference on E-Commerce and Web-Technology," entitled "Dynamic Agents, Workflow and 

29 XML for E-Commerce Automation" But Chen, et al.'s solution is homogeneous and requires 

30 that agents be built upon a common infrastructure. 
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1 A few E-Commerce systems also support conversations between services. However, 

2 these systems all require that the client and service developers implement matching conversation 

3 control policies. 

4 For example, RosettaNet' s Partner Interface Processes (PIPs) specify roles and required 

5 interactions between two businesses, while Commerce XML (cXML) is a proposed standard 

6 being developed by more than 50 companies for business-to-business electronic commerce. 

7 However, both RosettaNet and CommerceOne require that participating services pre-conform 

8 to their standards. 

9 To illustrate, in an E-Service marketplace with two different enterprises, a client service 



10 in one enterprise may have discovered a storefront service in another enterprise. In order to 

1 1 complete a sale, a credit validation service in yet another enterprise may be employed by the 

12 storefront service to make sure that the client is credible. These services can communicate by 

1 3 exchanging messages using common transports and message formats. The storefront service may 

14 expect that message exchanges, i.e., the conversation, to follow a specific pattern. So does the 

15 credit validation service. Because the client and the storefront services belong to different 

16 enterprises and have discovered each other dynamically, the client service may not know what 

17 conversations the storefront service supports. Similarly, the credit validation service may not 

1 8 know what conversations the client service or the storefront service supports. Accordingly, 

1 9 explicit conversation control implementation may be needed to conduct a conversation between 

20 the client service and the storefront service, between the client service and the credit validation 

21 service, and between the storefront service and the credit validation service. 

22 Accordingly, current conversation systems require participating service developers to 

23 implement logic code to adhere strictly to pre-defined conversation policies. Should a 

24 conversation protocol change, all participating services that support the protocol must be updated 

25 and recompiled, reducing the likelihood that two services that discover each other will be able 

26 to converse spontaneously. 

27 Summary 

28 A mechanism for implementing a conversation between two services provides for a 

29 conversation controller that may act as a proxy to an E-Service, enabling the service to engage 

30 in complex interactions with other services without the service developers having to implement 
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1 code to manage conversation logic. Once the conversation controller receives a message, 

2 typically from a client, on behalf of a service, the conversation controller may determine a current 

3 state of the conversation and a valid input document type for the current state, verify whether the 

4 message is of the valid input document type for the current state, and dispatch the message to 

5 appropriate service entry points provided by the service, until the service produces an output 

6 document of a valid output document type. 



7 An embodiment of the mechanism may also direct the client's side of a conversation, so 

8 that the client and the service may carry out an entire conversation without either the client or the 

9 service developer having to implement any explicitly conversation control mechanisms. 

1 0 An embodiment of the mechanism may also apply a transformation to output documents, 

1 1 for example, transforming the output documents to a hypertext markup language (HTML) form, 

12 Description of the Drawings 

1 3 The preferred embodiments of a conversation controller will be described in detail with 

14 reference to the following figures, in which like numerals refer to like elements, and wherein: 

1 5 Figure 1 is a flow chart demonstrating how an exemplary conversation controller receives 

1 6 and manages a message on behalf of a service; 

17 Figure 2 illustrates how the exemplary conversation controller directs a client's side of 

18 a conversation; 

1 9 Figure 3 is a block diagram illustrating the components of the exemplary conversation 

20 controller; 

21 Figure 4 illustrates in detail how the exemplary conversation controller manages a 

22 message on behalf of a service; 

23 Figure 5 shows an example demonstrating how service developers may be able to engage 

24 in inter-enterprise conversation without having to implement explicit conversation control; and 

25 Figure 6 illustrates exemplary hardware components of a computer that is used to 

26 implement the present invention. 

27 Detailed Description 

28 E-Services interact by exchanging messages. Each message can be expressed as a 

29 structured document that is an instance of a document type. For example, a message may be 

30 expressed using extensible markup language (XML) schema. The message may be wrapped in 
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1 an encompassing document, which can serve as an envelope that adds contextual information 

2 using, for example, Simple Object Access Protocol (SOAP). SOAP is a lightweight protocol for 

3 exchange of information in a decentralized, distributed environment. SOAP consists of three 

4 parts: an envelope that defines a framework for describing what is in a message and how to 

5 process the message, a set of encoding rules for expressing instances of application-defined 

6 datatypes, and a convention for representing remote procedure calls and responses. SOAP can 

7 potentially be used in combination with a variety of other protocols. 

8 A conversation may be a sequence of message exchanges between two or more services. 

9 Conversations typically model loosely-coupled interaction between services, rather than 

10 workflow processes. In another words, conversations typically define externally visible 

1 1 commerce processes instead of business logic, and are typically transactional only at the end of 

12 the conservation. A conversation specification, also known as a conversation policy, may be a 

13 formal description of a set of "legal" message type-based conversations supported by a service. 

14 Instead of requiring service developers to implement logic code to adhere strictly to pre- 

1 5 defined conversation policies, a mechanism provides for a conversation controller that enables 

16 services to carry out an entire conversation without the service developers having to implement 

1 7 code to manage conversation logic. 

1 8 The mechanism focuses on conversation functionality, such as flow control and other 

19 routines of the conversation, as opposed to business functionality of the service, such as quality 

20 of service and other management of the conversation. The mechanism enables service 

2 1 developers to delegate conversational responsibilities to the conversation controller, thus freeing 

22 the developers from having to implement explicit conversation control mechanisms and allowing 

23 the services to interact even if the services don't support precisely matching conversations. 

24 These distinctions help to provide an extremely lightweight conversation controller capable of 

25 directing a service's conversations with other services or clients. The conversation controller 

26 may dynamically execute a service' s conversation logic given a minimum amount of information. 

27 The conversation controller may also control a client's side of the conversation. 

28 The mechanism may be completely compatible with existing E-Commerce systems that 

29 support conversations between E-Services, such as RosettaNet's Partner Interface Processes 

30 (PIPs) and Commerce XML (cXML). 
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1 The conversation controller is a third party service that is capable of facilitating a 

2 conversation between two other services. The conversation controller may act as a proxy to 

3 services and track the state of an ongoing conversion based on a conversation definition language 

4 specification. The conversation controller may also invoke appropriate service and/or client entry 

5 points based on dispatch service description language specifications and prompt for valid input 

6 document types for a given state of a conversation, thus enabling the services and clients to 

7 engage in complex interactions with each other. 

8 Once the conversation controller receives a message on behalf of a service, the 

9 conversation controller may validate that each message is of an appropriate input document type 

1 0 for the current state of the conversation and dispatch the message to the appropriate service entry 

1 1 point based on the state of the conversation and the message's type. The conversation controller 

1 2 may use the resulting output document types to identify the next appropriate interaction for the 

1 3 conversation, and may include a prompt indicating valid document types that are accepted by the 

14 next stage of the conversation when forwarding a response from the service to the client. The 

1 5 prompt may optionally be filtered through a transformation appropriate to the client's type. For 

16 example, if the client is a web browser and has indicated a preference for form output, the 

17 conversation controller may transform the response into an HTML form before sending the 

1 8 response to the client. In addition, if the client requests and specifies appropriate entry points, 

19 the conversation controller may direct the client's side of the conversation (described later), so 

20 that neither the service nor the client developer may need to implement any explicit conversation 

21 control mechanism. 

22 When a conversation proceeds from one state to another, a "state" of the conversation, 

23 which contains information of the current state, may need to be tracked. If the conversation 

24 controller maintains the state of the conversation, the conversation controller may be referred to 

25 as stateful However, if the "state" of the conversation is carried in the message and passed from 

26 the client and the server to the conversation controller, the conversation controller may be 

27 referred to as stateless. A stateless conversation controller may be easier to implement, while a 

28 stateful conversation controller may be extended to implement performance management, 

29 conversation history, or rollback mechanisms, and thus may be more effective in handling issues 

30 such as malicious behavior on the part of one of the participants. 
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1 In order for a service to use the conversation controller as a proxy, the service may need 

2 to communicate two documents, typically XML-based, to the conversation controller. The first 

3 document to be communicated may be a conversation specification, i.e., a specification of the 

4 structure of the conversations supported by the service. The second document to be 

5 communicated may be a document-based specification mapping valid input document types and 

6 service entry points to potential output document types. 



7 Accordingly, a developer of the service may need to document the service' s conversation 

8 flow in a specification, document the type-based inbound handling entry points in a specification 

9 that preferably capture both input and output document types, and advertise the service with an 

1 0 entry point going through the conversation controller. 

1 1 Figure 1 is a flow chart demonstrating in general how the conversation controller receives 



12 and manages a message on behalf of the service. After the conversation controller receives a 

13 message on behalf of a service, step 110, the conversation controller may determine a current 

14 state of the conversation, step 120. The conversation controller may ask the service for 

15 conversation specifications, if necessary. Next, the conversation controller may determine the 

16 valid input document types for the current state from the conversation specifications, step 130, 

17 and verify whether the current message is of a valid input document type for the current state, 

18 step 140. 

19 If the received message is of a valid type, the conversation controller may dispatch the 

20 message to an appropriate service entry point provided by the service, step 150. If the service 

2 1 does not produce an output document of a valid document type, step 1 60, and if more than one 

22 appropriate service entry point exists, step 170, the conversation controller may dispatch the 

23 message to each entry point, step 1 50, until the service produces an output document of a valid 

24 document type. If no entry point exists or no valid output document is produced, the 

25 conversation control may raise an exception, step 190. 



26 Given the document type of the output document returned by the service, step 160, the 

27 conversation controller may calculate a new state of the conversation, step 1 80, and determine 

28 valid input document types for the new state of the conversation, step 200. 

29 Finally, the conversation controller may format the output document in a form appropriate 

30 to the client and prompt for new input document types that are valid in the new state, step 210, 
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1 for a new interaction. In step 210, the conversation controller may apply requested 

2 transformations to the output document, for example, transforming the output document into an 

3 HTML form and prompting the client for valid input documents. 

4 The conversation controller may maintain and track the "state" of the conversation, i.e., 

5 implemented as stateful, step 212, or may retrieve the "state" of the conversation from the 

6 service, i.e., implemented as stateless, step 214. 

7 E-Service clients may also want the conversation controller to direct the client's side of 



8 the conversation. Decoupling conversation logic from business logic on the client side may 

9 greatly increase the flexibility of a client by allowing the client to interact dynamically with 

10 services even if the client's and the services' conversation policies do not match exactly. For 

1 1 example, the same client code may be used to interact with two services that support different 

1 2 conversation policies. 

13 Figure 2 illustrates in general how the conversation controller directs a client's side of a 

14 conversation. In order for the conversation controller to direct the client's side of the 

1 5 conversation, the client, typically a web browser client that can return a specification of the 

16 client's own service entry points, may need to be able to communicate the client's service 

1 7 interfaces to the conversation controller, so that the conversation controller may automatically 

1 8 send the output message to appropriate client entry points. 



19 Referring to Figure 2, following step 200 of Figure 1, if the client wishes to be directed 

20 by the conversation controller, step 220, and there are valid input document types for the new 

2 1 state, step 230, the conversation controller may look up outbound document types in a dispatch 

22 table of the client, and invoke appropriate client methods that may produce new input documents 

23 that are valid in the new state, step 240. 

24 If the client produces the new input documents that are valid in the new state, step 250, 

25 the conversation controller may send the new input documents to the service, step 260, moving 

26 the conversation forward dynamically. 

27 On the other hand, if the client does not produce any valid new input documents, step 

28 250, or if there are no valid new input document types in the new state, step 230, the conversation 

29 controller may format and return the output document to the client, and prompt for new input 

30 document types that are valid in the new state, step 210 of Figure 1 . 
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1 Therefore, the lightweight dynamic conversation controller, acting as a proxy for the 

2 service and/or the client, can help multiple services carry out an entire conversation without 

3 either the client or the service developer having to implement any explicit conversation control 

4 mechanisms, so that a developer of the client may not need complete knowledge of all of the 

5 possible conversations supported by all the services with which the client might interact in the 

6 future. 



7 In order to track the state of conversations, the conversation controller may perform the 

8 following functions. Given a message, the conversation controller may determine the 

9 conversation specification that represents the type of conversation, an interaction identifier that 

10 represents the stage of the ongoing conversation, and document type of the message body. 

1 1 In order to accomplish these functions, the conversation controller may give each message 

12 a special context element, such as the following: 

13 <Context> 

14 <ConversationID/> 

15 <In-Reply-To/> 

16 <Reply-With/> 

17 </Context> 

18 Each of these elements may have an "owner" that controls the contents of the element 



1 9 value. The conversation controller, for example, may own the ConversationID field, which may 

20 be used to map the current interaction and the valid input document types for the current 

2 1 interaction of the current conversation to the conversation type identifier. A message sender, for 

22 example, may own the Reply- With element. The In-Reply-To elements' s value may be the value 

23 of the Reply- With element of the message to which the current message is responding. 

24 In addition to the above described function, given a conversation specification and an 

25 interaction identifier, the conversation controller may return document types that are accepted 

26 as valid input to that interaction. Furthermore, given a conversation specification, an interaction 

27 identifier from the specification, and a document type representing an input document, the 

28 conversation controller may return a boolean signal indicating whether or not the document type 

29 may be accepted as a valid input for that interaction. Similarly, given a conversation 

30 specification, a source interaction identifier from the specification, and a document type 
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1 representing an output document, the conversation controller may return a target interaction 

2 represented by the transition from the source interaction. 

3 These functions may be satisfied, for example, by populating two hash tables each time 

4 when the conversation controller reads a new conversation specification expressed, for example, 

5 in CDL. One table may map from interaction identifiers to valid input document types and 

6 another table may map from source interaction identifier and transition document types to target 

7 interaction identifiers. The conversation controller may use the first table to look up the valid 

8 input document types for a given interaction, and use the second table to determine when a 

9 conversation has progressed from one interaction state to another, given the document type of 

10 an output document and a source interaction identifier. 

1 1 As another example, in order to forward messages to appropriate service entry points, an 

12 endpoint binding specification, for example, a WSDL specification, may be created for each 

1 3 service so that the conversation controller may map input and output document types to service 

14 entry points. Each time the conversation controller reads a specification, the conversation 

1 5 controller may populate another two hash tables: one that maps from input document types to 

16 service entry point and output document types, and one that maps from output document types 

1 7 to service entry point and input document types. 

1 8 Figure 3 is a block diagram illustrating the components of a conversation controller 300, 

19 from the perspective of how the conversation controller 300 manages messages from a client 360 

20 to a service 370. An incoming context handler 310 may include a logic that manages message 

21 structure, and may be responsible for restoring contextual information packed in incoming 

22 message headers to its original format. An outgoing content handler 320 may be responsible for 

23 packing contextual information into outgoing message headers and composing outgoing 

24 messages. An interaction handler 330 may parse and query conversation definitions to, for 

25 example, validate document types or calculate new conversation states. The interaction handler 

26 330 may also raise exceptions when an invalid type document is received. A dispatch handler 

27 340 may parse and query service descriptions, typically specified in WSDL, and use the service 

28 descriptions to forward messages to the service 370. An optional client interaction controller 

29 handler 350 and interactions, drawn with dotted lines, may dispatch a reply from the service 370 
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1 to the client 360 and then forward the client's response back to the service 370 by way of the 

2 conversation controller 300. 

3 Figure 4 illustrates in detail how the conversation controller 300 manages a message on 

4 behalf of a service 370. Each time the conversation controller 300 receives a message on behalf 

5 of the service 370, step 41 0, the incoming context handler 3 1 0 may parse the incoming message, 

6 and extract or initialize the message's context data, step 420. The interaction handler 330 may 

7 use the data to identify the current state, conversation specification, typically specified in CDL, 

8 and document type represented by the incoming message, 425. Then the interaction handler 330 

9 may validate whether or not the document type of the incoming message is valid for the current 

10 state, step 430. 

11 If the incoming message is of a legitimate type, the dispatch handler 340 may parse the 

12 service's specification and forward the message to an appropriate service entry point, step 440. 

13 If the message's type is not legitimate, the conversion controller may trigger an appropriate 

14 exception transition, typically defined in advance, and inform the client of the valid input 

1 5 document types. When the service 370 returns a response message > i.e., output document, step 

16 450, the interaction handler 330 may use the document type of the response message and the 

1 7 conversation specification to identify a new state of the conversation as well as the new state's 

18 valid input document types, step 455. If the response document type is not valid, the 

19 conversation controller may take exception transitions into account. The outgoing content 

20 delivery handler 3 20 may build an outgoing message context element from the response message, 

21 and compose an outgoing message to return to the client 360, step 460. 

22 If the client service has requested that the conversation controller direct the client's side 

23 of the conversation and has provided a specification for the client 360 itself, the client interaction 

24 handler 350 may identify and dispatch to an appropriate client entry point that may produce an 

25 appropriately typed document using the client specification, step 470. If the client 360 produces 

26 a valid document for the new state, the client interaction handler 350 may forward the message 

27 back to the conversation controller 300 and start a new cycle, step 480. 

28 Finally, the conversation controller 300 may return the message back to the client 360 and 

29 prompt for next legal input document, step 490. 
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1 Figure 5 illustrates how service developers may be able to engage in inter-enterprise 

2 conversation without having to implement explicit conversation control. In the example 

3 illustrated above in the background section, a client 510 service in one enterprise may have 

4 discovered a storefront 520 service in another enterprise. In order to complete a sale, a credit 

5 validation 530 service in yet another enterprise may be employed by the storefront 520 service 

6 to make sure that the client 5 1 0 is credible. 

7 By using a conversation controller 3 00, the storefront 520 service developer may be freed 

8 from having to code the conversation-controlling logic directly into the service or to re- 

9 implement the client 5 1 0 and storefront 520 services each time a new message exchange is added 

10 to the supported conversation. The conversation controller 300 may also free the credit 

1 1 validation 530 service from having to implement logic code to adhere strictly to pre-defined 

12 conversation policies established by either the storefront 520 service or the client 510 service. 

1 3 Figure 6 illustrates exemplary hardware components of a computer 600 that may be used 

14 with the conversation controller. The computer 600 includes a connection with a network 618 

1 5 such as the Internet or other type of computer or phone networks. The computer 600 typically 

16 includes a memory 602, a secondary storage device 612, a processor 614, an input device 616, 

17 a display device 610, and an output device 608. 

18 The memory 602 may include random access memory (RAM) or similar types of 

19 memory. The memory 602 may be connected to the network 61 8 by a web browser 606. The 

20 web browser 606 makes a connection by way of the WWW to other computers known as web 

21 servers, and receives information from the web servers that is displayed on the computer 600. 

22 Information displayed on the computer 600 is typically organized into pages that are constructed 

23 using specialized language, such as HTML or XML. The secondary storage device 612 may 

24 include a hard disk drive, floppy disk drive, CD-ROM drive, or other types of non- volatile data 

25 storage, and may correspond with various databases or other resources. The processor 614 may 

26 execute information stored in the memory 602, the secondary storage 612, or received from the 

27 Internet or other network 618. The input device 616 may include any device for entering data 

28 into the computer 600, such as a keyboard, key pad, cursor-control device, touch-screen (possibly 

29 with a stylus), or microphone. The display device 610 may include any type of device for 

3 0 presenting visual image, such as, for example, a computer monitor, flat- screen display, or display 
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1 panel. The output device 608 may include any type of device for presenting data in hard copy 

2 format, such as a printer, and other types of output devices include speakers or any device for 

3 providing data in audio form. The computer 600 can possibly include multiple input devices, 

4 output devices, and display devices. 

5 Although the computer 600 is depicted with various components, one skilled in the art 

6 will appreciate that the computer can contain additional or different components. In addition, 

7 although aspects of an implementation consistent with the present invention are described as 

8 being stored in memory, one skilled in the art will appreciate that these aspects can also be stored 

9 on or read from other types of computer program products or computer-readable media, such as 

1 0 secondary storage devices, including hard disks, floppy disks, or CD-ROM; a carrier wave from 

1 1 the Internet or other network; or other forms of RAM or ROM. The computer-readable media 

12 may include instructions for controlling the computer 600 to perform a particular method. 

13 While the conversation controller has been described in connection with an exemplary 

14 embodiment, it will be understood that many modifications in light of these teachings will be 

1 5 readily apparent to those skilled in the art, and this application is intended to cover any variations 

1 6 thereof 
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